Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encode complex types in section mangling #1199

Merged
merged 6 commits into from
Jun 13, 2024

Conversation

CohenArthur
Copy link
Contributor

Needs #1198

This PR allows the section mangler to encode more type information in order to specify structs, enumerations, arrays and aliases. There are still some missing bits, e.g. regarding the length of arrays

@CohenArthur CohenArthur force-pushed the encode-complex-types branch 2 times, most recently from 0c26c1c to be78df6 Compare April 18, 2024 11:04
Copy link

codecov bot commented Apr 18, 2024

Codecov Report

Attention: Patch coverage is 94.33962% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.11%. Comparing base (fedc06d) to head (be78df6).
Report is 22 commits behind head on master.

Current head be78df6 differs from pull request most recent head 54e08eb

Please upload reports for the commit 54e08eb to get more accurate results.

Files Patch % Lines
src/codegen/generators/pou_generator.rs 90.90% 1 Missing ⚠️
src/codegen/generators/section_names.rs 95.00% 1 Missing ⚠️
src/codegen/generators/variable_generator.rs 90.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1199      +/-   ##
==========================================
- Coverage   95.62%   91.11%   -4.51%     
==========================================
  Files         150      153       +3     
  Lines       42657    44816    +2159     
==========================================
+ Hits        40789    40833      +44     
- Misses       1868     3983    +2115     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

// the same. Therefore, only encode it as its underlying type.
DataTypeInformation::SubRange { referenced_type, .. } => access_inner(referenced_type)?,
DataTypeInformation::Generic { .. } | DataTypeInformation::Alias { .. } => {
// FIXME: Is that correct?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, generics and aliases will be resolved to the correct types during the resolve phase.

DataTypeInformation::Array { inner_type_name, .. } => {
Type::Array { inner: Box::new(access_inner(inner_type_name)?) }
}
// FIXME: Is that correct?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the range is only relevant at compile time AFAIK.
Technically the norm allows for different runtime behaviour if a value is out of range, but this would still not affect the generated type, only some functions that the user needs to have.
The subrange has an implicit method that gives the upper and lower bounds but this is resolved on compile time as well since the range is known.

ghaith
ghaith previously approved these changes Jun 3, 2024
@CohenArthur
Copy link
Contributor Author

@ghaith rebased properly, sorry for the confusion :)

@ghaith ghaith merged commit a9d55a1 into PLC-lang:master Jun 13, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants